Boo🧨

Асап, так получилось, что я отсутствовал полтора года. Но вроде как, теперь есть вариант писать сюда. Пробуем новый, тестовый формат, где я описываю обезличенные случаи из своей практики AppSec.

В рамках такого формата, хотелось бы поговорить про самую частую уязвимость, которую я находил в своих проектах. Это broken access control.

Стоит отметить, что понятие уязвимости, которое может вписываться в эту категорию всегда будет разным. Так например одна уязвимость, которую можно "занести" на Bug Bounty и уяза, которую можно зарепортить во время тестирования безопасности сервиса - может иметь разную оценку по критичности.

Теперь когда с этим разобрались можно приступать к основной части.

По идее нарушенный контроль доступа или же B.A.C. (почти как ACAB) это уязвимость в веб-приложении которая позволяет злоумышленнику получить доступ к функциональности, для эксплуатации которой у него нет прав. Для этого очевидно, в приложении должна быть реализована ролевая модель. Или нет? Давайте разберем два случая. Когда она есть и когда ее нет.

В рамках тестирования сервиса X на Bug Bounty, удалось использовать уязвимость нарушенного контроля доступа чтобы запостить новость в афише от имени администратора, прикрепив туда изображение в формате svg, которое содержит в себе полезную нагрузку для триггера XSS уязвимости. Получается, что тут 2 проблемы. Это небезопасная загрузка файлов и IDOR. Если первая уяза совершенно не по теме, давайте разберемся с нашим контролем доступа.

В моем случае сервис посылал POST запрос на создание новости в афише. Изучив api, я смог посмотреть какие параметры передются в JSON через этот POST запрос и подметил для себя тот факт, что в запросе передаётся user id и другой параметр, который проверял прошла ли новость модерацию. Изменив user id на id администратора и исправив другой параметр с false на true, я получил IDOR на стероидах, который из-за отсутствия корректной валидации данных параметров со стороны обычного пользователя, без привилегий позволяет нам создать фейковую новость с кликбейтным названием, плюс ко всему еще и тригерит наш Stored XSS.

Если ролевая модель толком не реализована и сервис не позволяет нам работать через POST, PUT и PATCH запросы - имеет смысл провести разведку API для выявления "подозрительных ручек". Например сервис X не позволяет пользователям вносить изменения на стороне сервера, однако это еще не значит, что вектор нарушенного контроля доступа надо вычеркивать из флоу тестирования. В рамках тестирования, уязвимостью нарушенного контроля доступа может считаться страница, где производиться вход в админку, получаются данные дургих пользователей сервиса (критичность уязы в таком случае зависит от контекста приватности информации) или даже доступ в /metrics, где будут разглашены внутренние хосты и весь api.

Увидимся на Confab

Всем привет !

Сегодня хочется поделится чуть-чуть своим опытом проведения технических собеседований в рамках Application Security.

Соответсвенно поделим пост на две части. Сначала расскажу про опыт ведения собеседований, а в следующем посте расскажу, каково быть кандидатом в рамках такого рода интервью.

Вот что я подметил для себя:

1. AppSec крайне непонятный объект, который все компании и соответсвенно кандидаты на интервью видят по разному. Но условно можно поделить на три вида:

1) Когда безопасим только через сканирование кода (SAST, DAST) и тд.

2) Когда можем поаудировать веб, выстроить Арх ревью и поддерживать SSLDC.

3) тоже самое что второй вариант + еще есть компетенции для аудита докера и k8s (extra hard level).


2. По моим ощущениям, требования в больших компаниях от джуна такие же как пару лет назад от крепкого мидла. В этом плане, действительно ребятам, которые начали погружаться относительно не давно предстоят пройти не простой путь для реализации себя, однако все не так плохо, так как если кандидат технически подкован в вебчике - его сложно не заметить.

3. Темы которые хромают у кандидатов, зачастую плюс минус одинаковые. Ими являются:
1) Sop и CORS.
2) Виды Грантов Oauth 2.0
3)Некорректное понимание реализации http, которое ведет к «непоняткам» по клиентским уязвимостям.
4) Браузерные хранилища и их разница.
5) Атрибуты безопасности Cookie (в особенности SameSite)
6) Импакт от уязвимости вида File upload. 99 процентов кандидатов говорит от reverse shell и rce, но упускают path traversal, скулю, XSSку, перезапись файлов и тд.
7) CSP, митигация Dom XSS

Скоро новый пост 🥷

эх Пашок

Поучаствовал в создании статьи для мейла

https://hi-tech.mail.ru/review/124705-spetsialist-po-informatsionnoj-bezopasnosti/#anchor174314712806481185